## Explanation

Release PR for transaction-pay-controller.

## References
Related to: https://consensyssoftware.atlassian.net/browse/CONF-1324

## Checklist

- [X] I've updated the test suite for new or updated code as appropriate
- [X] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [X] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [X] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Release metadata-only changes (version bumps and changelog/link
updates) with no runtime logic modifications.
> 
> **Overview**
> Bumps the monorepo version to `969.0.0` and releases
`@metamask/transaction-pay-controller` `22.1.0`.
> 
> Updates the `transaction-pay-controller` changelog for `22.1.0`
(documenting the Arbitrum USDC/accountOverride fix) and adjusts the
compare links to point `Unreleased` at the new tag.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
f1e23fe. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

… empty contract (#8744)

## Explanation

`TransactionController` would silently classify a transaction with no
recipient and no real bytecode as a contract deployment and broadcast
it, creating an empty contract on-chain with any `value` permanently
locked inside.

The root cause is that `'0x'` is a non-empty string, so `if (data)`
truthiness checks in `validateParamRecipient` and
`determineTransactionType` treated it as real deployment bytecode.
`validateParamRecipient` also didn't recognize `to === ''` as missing.

Validation now treats `to === ''` as missing alongside `'0x'` /
`undefined`, and both the validator and the type classifier require
`data.length > 2` before accepting a missing recipient as a legitimate
deployment.

## References

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [x] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Tightens core transaction validation/type inference around contract
deployments; could cause some previously-accepted malformed transactions
to be rejected or reclassified, but the change is narrowly scoped and
well-covered by tests.
> 
> **Overview**
> Prevents accidental empty contract deployments by treating missing
recipients (`to` of `''`, `'0x'`, or `undefined`) as **invalid unless**
`data` contains *real* deployment bytecode (more than just `'0x'`).
> 
> Updates both `validateTxParams`/`validateParamRecipient` and
`determineTransactionType` to require non-empty bytecode before allowing
a missing `to`, adds targeted unit tests for the new edge cases, and
records the fix in the `transaction-controller` changelog.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
7154b2f. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

…8631)

## Explanation

Currently `deriveFiatAssetForFiatPayment` resolves the fiat asset for a
payment entirely from a hardcoded map (`FIAT_ASSET_ID_BY_TX_TYPE`). This
makes it impossible to adjust asset mappings without a code release.

This PR introduces a 3-tier resolution for fiat assets:

1. **Feature flag** - reads from
`confirmations_pay_fiat.assetPerTransactionType[txType]` via
`RemoteFeatureFlagController`
2. **Hardcoded map** - falls back to the existing
`FIAT_ASSET_ID_BY_TX_TYPE` constant
3. **ETH on mainnet** - terminal fallback when neither source has an
entry

The function signature gains a `messenger` parameter (already available
at the call site in `fiat-quotes.ts`), and the return type tightens from
`TransactionPayFiatAsset | undefined` to `TransactionPayFiatAsset` since
the ETH mainnet fallback guarantees a value.

## References

- Feature flag key: `confirmations_pay_fiat`

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [x] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them


<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Medium risk because it changes fiat on-ramp asset resolution and CAIP
asset identifiers used for quote fetching and order validation, which
can affect MM Pay fiat quote/submit flows across transaction types.
> 
> **Overview**
> **Fiat-asset selection is now remotely configurable.** Fiat strategy
resolves the source fiat asset per transaction type from the
`confirmations_pay_fiat.assetPerTransactionType` remote feature flag,
falls back to the existing hardcoded map, and finally defaults to
*mainnet ETH*.
> 
> **CAIP asset identifiers are now derived, not stored.**
`TransactionPayFiatAsset` no longer carries `caipAssetId`/`decimals`;
call sites now build CAIP-19 via new `buildCaipAssetType(chainId,
address)` and fetch decimals via `getTokenInfo`, updating ramps token
selection, quote requests, and fiat order validation accordingly, with
tests updated to cover the new resolution and fallbacks.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
15f1c3d. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

## Explanation

Feature release for `json-rpc-engine` introducing a legacy version of
`createOriginMiddleware`.

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

## Checklist

- [ ] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [ ] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Primarily a coordinated version/dependency bump to
`@metamask/json-rpc-engine@10.4.0` plus changelog updates; no runtime
logic changes in this diff beyond pulling in the new engine release.
> 
> **Overview**
> Bumps the monorepo release version to `970.0.0` and publishes
`@metamask/json-rpc-engine` as `10.4.0` (changelog notes the addition of
the legacy `createOriginMiddleware`).
> 
> Updates dependent packages to require
`@metamask/json-rpc-engine@^10.4.0`, refreshes related `CHANGELOG.md`
entries, and updates `yarn.lock` accordingly.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
1c24a4b. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

## Explanation

Exports the `assertExpectedHooks` utility which is helpful when creating
middlewares using `selectHooks`.

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [ ] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk: this is a surface-area change that only adds a new named
export and updates tests/changelog, with no behavioral changes to
request handling.
> 
> **Overview**
> Exposes the `assertExpectedHooks` helper as a public export from
`@metamask/json-rpc-engine/v2` (re-exported from `utils`).
> 
> Updates the v2 export snapshot test to include the new symbol and
notes the addition in the package changelog.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
d0b1873. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->